I do not think we need to worry about changes to the serviceAccount name or role binding itself. IRSA is external to Splunk and operates at the pod level to provide temporary AWS credentials. As long as the pod is correctly annotated and associated with the IAM role, IRSA will continue to function independently of Splunk’s internal logic.

Separately, and unrelated to Ingestion and Indexing separation, we should consider what happens if the AWS secret changes in the SmartStore configuration. That scenario also requires attention. If object storage credentials are updated, we need a well-defined mechanism to ensure the new credentials are picked up safely and consistently.

Given these cases, the restart logic needs to be revisited. Instead of implementing custom coordination logic inside the controller, we should rely on Kubernetes-native mechanisms. For example:

• Let Kubernetes make eviction decisions based on Pod Disruption Budgets.
• Use standard StatefulSet rolling restart behavior where appropriate.
• Ensure that any SmartStore configuration changes are applied via Ansible and/or init containers during pod restart.

The goal should be to keep the operator lightweight and defer restart orchestration to Kubernetes wherever possible, rather than embedding complex restart coordination inside the controller.

SmartStore is not implemented to Index and Ingestion separation, so that's a separate case as mentioned by you. We might want to get back to this topic in the nearest future.

Yes, we need to revisit the restart implementation. I created a task as asked by you and we might want to look into this soon.